-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dockerized LLVM #1914
Dockerized LLVM #1914
Conversation
looks good so far, I see the |
@mvines. The WIP is more to sync up with what you have in mind. This is working but is setup so that we run llvm from within Docker. With the Travis building and posting binaries in release tags would we still be building in a docker? |
@jackcmay Running llvm in docker is loosely defined, as you are right: travis would be creating the binaries. However, do you have any ways to verify a built toolchain? As if anyone is building it, the docker file would just download it from there. . . This type of thing is admirable, but I think after this is committed, the resultant binary (docker container) should be tagged and pushed to dockerhub to be repulled for veracity's sake against the version you successfully built. Deeper conversation should be had about dedicating the toolchains to a repository and the levels of veracity one places on correctly building to a known good standard. I have not see gpg checksums on built toolchains unless one is downloading them directly or building them from source like bitbake or LEDE on Openwrt. @mvines is there any discussion for ground up veracity on the resultant blockchain? I wonder what portions you all are building besides the applications? I assume the blockchain computation backend needs compiling? |
Probably not, ideally we can use the native binaries directly. But the docker setup still has value in the short term, in that we'd likely first get Travis building Linux LLVM binaries, so macOS could continue to use the docker image until we get Travis building macOS LLVM binaries. For Windows support I feel that we can just create a new issue for it and one day somebody may be motivated enough to pick it up. |
@borromeotlhs |
7152f29
to
501cb79
Compare
501cb79
to
f3eb95a
Compare
@echo ' V=1' | ||
@echo ' - Show commands while building: V=1' | ||
@echo ' V=$(V)' | ||
@echo ' - Use LLVM from docker: DOCKER=1' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
probably should document somewhere around here that the user needs to docker pull solanalabs/llvm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't docker do that automagically if it does not find the docker locally?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nerp
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about pull as part of the script or is that just wasteful?
#!/usr/bin/env bash
set -ex
SDKPATH="$( cd "$(dirname "$0")" ; pwd -P )"/../../../..
docker pull solanalabs/llvm
docker run --workdir /solana_sdk --volume $SDKPATH:/solana_sdk --rm solanalabs/llvm `basename "$0"` "$@"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ci/docker-run.sh
does this, but there's also cases when you don't want to pull (you're on an airplane with no uplink) so if we autopull then we'd also want to add a way to disable it. My vote for now is to just document that the user must pull
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
r+ with doc nits picked
…olana-labs#1914) Bumps [@babel/cli](https://github.com/babel/babel/tree/HEAD/packages/babel-cli) from 7.14.3 to 7.14.5. - [Release notes](https://github.com/babel/babel/releases) - [Changelog](https://github.com/babel/babel/blob/main/CHANGELOG.md) - [Commits](https://github.com/babel/babel/commits/v7.14.5/packages/babel-cli) --- updated-dependencies: - dependency-name: "@babel/cli" dependency-type: direct:development update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
* build(deps): bump num-bigint from 0.4.5 to 0.4.6 Bumps [num-bigint](https://github.com/rust-num/num-bigint) from 0.4.5 to 0.4.6. - [Changelog](https://github.com/rust-num/num-bigint/blob/master/RELEASES.md) - [Commits](rust-num/num-bigint@num-bigint-0.4.5...num-bigint-0.4.6) --- updated-dependencies: - dependency-name: num-bigint dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <[email protected]> * Update all Cargo files --------- Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Problem
BPF programs will soon require customized LLVM toolchain
Summary of Changes
Sync and build LLVM in docker and with 2 stage docker image make the binaries available to run directly. This docker is optionally used to build BPF programs.
Further changes are coming to populate this docker with the llvm binaries build and released separately.
Fixes #